The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application merely by virtue of their inclusion in this section.
Relational database management systems (RDBMS) store information in tables, where each piece of data is stored at a particular row and column. Information in a given row generally is associated with a particular object, and information in a given column generally relates to a particular category of information. For example, each row of a table may correspond to a particular employee, and the various columns of the table may correspond to employee names, employee social security numbers, and employee salaries.
A user retrieves information from and makes updates to a database by interacting with a database application. The user's actions are converted into database operations by the database application. Multiple database operations may be part of a “database transaction”. Database transactions might involve hundreds or millions of operations and take minutes or hours to complete. If a transaction does not complete successfully, then the data in the database is in an interim state that is not planned and that is not desired. It is therefore useful for the database server to generate and store in an undo storage space an undo log containing undo records that indicate undo operations that may be performed to reverse the operations performed during the database transaction. Then, if the transaction fails to complete successfully, changes made by the database operations from the database transaction that have already been executed can be undone by performing the undo operations associated with the database operations. After the transaction completes, or after the unsuccessful transaction is undone, the undo data in the storage is considered obsolete and the storage allocated to the undo data may be re-allocated to another transaction.
Additionally, the information in the undo log for a database transaction may be used to provide consistent reads of data in a database. A consistent read allows a user of the database to query a database even if database transactions change the data in the database. The consistent read is designed to provide data from the database that reflects the last planned state of the database at the time the database query is initiated. In performing a consistent read, the database server handles data involved in an ongoing database transaction by using the undo log in the undo storage to determine the state of the database before the database transaction began executing. For example, a complex database query (which involves only database reads) involving thousands of rows of one or more tables may require minutes to complete. The database query may progress even if a database transaction has changed a particular row (or rows) on which the database query relies between the time the database query is initiated and the time the database query accesses the particular row. When accessing the particular row for the database query, the database server determines that the row has been changed since the start of the database query and uses undo information in the undo log to reconstruct the state of the row at the time the database query was initiated.
Storing undo information may be beneficial. A key consideration, however, is determining how much undo information to store. In a “store-all” approach to maintaining undo information, a database server stores undo information for every database operation that has occurred. A problem with the store-all approach is that, since the amount of stored undo information will grow indefinitely, storing the undo information places an undo burden on system resources, and in particular, the non-volatile memory, at the database server.
In a fixed-size approach, a fixed amount of non-volatile memory is dedicated to storing undo information. A problem with the fixed-size approach is that it provides no guarantee that a given piece of undo information will be available when it is needed.
Therefore, there is clearly a need for techniques that overcome the shortfalls of the approaches described above.